It is a well known requirement in the field of computer programming to be able to trace the execution path of a program by the recording of key data and events. The main reason for doing this is to be able to analyse the reasons for program failure by examining the recorded trace data. Alternatively, it might be required to analyse the performance of a program. Although tracing can, in some cases, be of direct assistance to end user customers it is primarily needed by customer support staff to assist their customers and also by the programming team which has developed the program.
For these reasons, many commercially available programs are written with an inbuilt trace facility, which may be enabled by the system administrator of the executing data processing system to provide and record trace data. Such data may include data indicating the timing and sequence of program methods which are called, such as, for example, timestamps, thread identifiers and the type of trace event. One example of a program offering such a trace facility is IBM WebSphere MQ (“IBM” and “WebSphere” are trademarks of International Business Machines Corporation). Trace data may also include actual program data values in registers, at the time of failure.
Because tracing program execution requires a great deal of computer time and storage, the default situation during normal program execution is that the trace facility is disabled. When, however, the trace facility is enabled, various techniques have been used to limit the impact on performance.
The simplest is inherent in the trace facility itself in that it allows the administrator to be selective as to which components of the program are to be traced and what level of detail is required. However, the actual tracing may still be very time consuming, particularly if the data is all logged to non-volatile storage, such as hard disk storage.
It is therefore common practice to record trace data in a transient buffer of sufficient size to hold only the immediate precursor data to a failure or other execution point of interest. In some systems, this may be examined on screen but more commonly, will be recorded to disk when or before the buffer becomes full. The use of a circular (wrap-around) transient buffer is also well known so that the oldest trace data is eventually overwritten by more recent trace data. One example of this is described in an article “Storing Variable Length Data in a Circular Buffer” by W C Carlson and M C Chang (IBM Technical Disclosure Bulletin Vol. 36, No. 3, pp 491-494, March 1993).
Another more recent approach to limiting the quantity of trace data to the most relevant is described in U.S. Patent Application Publication US 2004/0250242 A1 for a “Method, System and Computer Program Product for Tracing Software Methods” by R F Berry et al (IBM). This makes use of the call stack generated when a program is run, which includes a sequentially ordered list of methods called during the running of the program. Trace information of most significance is assumed to lie between minimum and maximum offsets in the call stack. The effective trace window between these offsets is varied adaptively according to predefined rules in order to limit the generation of too much extraneous trace data.
However, this and other existing approaches all have a performance overhead caused by the copying of trace data to the trace buffer. This action, like all data storage in a modem data processing system, involves a Memory Management Unit (MMU) which is the part of the system which controls the volatile storage attached to the processor. The normal operations carried out by the MMU are Load operations, in which data is retrieved from main memory and placed in one of the CPU (processor) caches, and Store operations, in which data from cache is stored back into the main memory. A Store operation, such as the copying of trace data to a circular trace buffer, necessarily takes up additional processor cycles thus slowing down execution of the actual program.